154 research outputs found
Le consentement du patient en droit de la santé
The appeal(recourse) to the care is daily thing for all the individuals. The latter are actually subjected(submitted) in their everyday life(daily paper) to the medical emanating constraint of "right-claim"("right-debt","law-claim") in the protection of the health planned in the paragraph 11 of the Introduction of the Constitution of 1946. Nevertheless, in a parallel to(at the same time as) this development of the access to healthcare, got free the subjective right(law) for the health which forbids any infringement(achievement) on the health of the individual. These two meanings of a word of the right(law) for the health interact to the point that the first one(night) becomes a real constraint for second. It is thus essential to find solutions so that a balance can become established between these two conceptions(designs). The consent in the care of the patient establishes(constitutes) validly a consequence of the subjective conception(design) of the right(law) for the health. Dedicated by the law of March 04th, 2002, relative to the rights of the patients, the right(law) for the consent arranges no fastening with an operating fundamental standard, for the moment. He(it) is in reality often reached(affected) by the appeal(recourse) compulsory for the care. This study thus attempts to demonstrate that the right(law) for the consent in the care presents a relative effectiveness and that it is then essential to connect him(it) with pre-existent fundamental rightLe recours aux soins est chose quotidienne pour l'ensemble des individus. Ces derniers sont effectivement soumis dans leur quotidien à la contrainte médicale émanant du "droit-créance" à la protection de la santé prévu à l'alinéa 11 du Préambule de la Constitution de 1946. Néanmoins, parallèlement à ce développement de l'accès aux soins, s'est dégagé le droit subjectif à la santé qui interdit toute atteinte à la santé de l'individu. Ces deux acceptions du droit à la santé interagissent au point que la première devienne une véritable contrainte pour la seconde. Il est donc indispensable de trouver des solutions afin qu'un équilibre puisse s'établir entre ces deux conceptions. Le consentement aux soins du patient constitue valablement une conséquence de la conception subjective du droit à la santé. Consacré par la loi du 04 mars 2002, relative aux droits des patients, le droit au consentement ne dispose d'aucun rattachement à une norme fondamentale opératoire, pour l'heure. Il se trouve en réalité souvent atteint par le recours imposé aux soins. Cette étude s'attache donc à démontrer que le droit au consentement aux soins présente une effectivité relative et qu'il est alors indispensable de le rattacher à des droits fondamentaux préexistan
PreciseBugCollector: Extensible, Executable and Precise Bug-fix Collection
Bug datasets are vital for enabling deep learning techniques to address
software maintenance tasks related to bugs. However, existing bug datasets
suffer from precise and scale limitations: they are either small-scale but
precise with manual validation or large-scale but imprecise with simple commit
message processing. In this paper, we introduce PreciseBugCollector, a precise,
multi-language bug collection approach that overcomes these two limitations.
PreciseBugCollector is based on two novel components: a) A bug tracker to map
the codebase repositories with external bug repositories to trace bug type
information, and b) A bug injector to generate project-specific bugs by
injecting noise into the correct codebases and then executing them against
their test suites to obtain test failure messages.
We implement PreciseBugCollector against three sources: 1) A bug tracker that
links to the national vulnerability data set (NVD) to collect general-wise
vulnerabilities, 2) A bug tracker that links to OSS-Fuzz to collect
general-wise bugs, and 3) A bug injector based on 16 injection rules to
generate project-wise bugs. To date, PreciseBugCollector comprises 1057818 bugs
extracted from 2968 open-source projects. Of these, 12602 bugs are sourced from
bug repositories (NVD and OSS-Fuzz), while the remaining 1045216
project-specific bugs are generated by the bug injector. Considering the
challenge objectives, we argue that a bug injection approach is highly valuable
for the industrial setting, since project-specific bugs align with domain
knowledge, share the same codebase, and adhere to the coding style employed in
industrial projects.Comment: Accepted at the industry challenge track of ASE 202
Empirical Study of Restarted and Flaky Builds on Travis CI
Continuous Integration (CI) is a development practice where developers
frequently integrate code into a common codebase. After the code is integrated,
the CI server runs a test suite and other tools to produce a set of reports
(e.g., output of linters and tests). If the result of a CI test run is
unexpected, developers have the option to manually restart the build,
re-running the same test suite on the same code; this can reveal build
flakiness, if the restarted build outcome differs from the original build. In
this study, we analyze restarted builds, flaky builds, and their impact on the
development workflow. We observe that developers restart at least 1.72% of
builds, amounting to 56,522 restarted builds in our Travis CI dataset. We
observe that more mature and more complex projects are more likely to include
restarted builds. The restarted builds are mostly builds that are initially
failing due to a test, network problem, or a Travis CI limitations such as
execution timeout. Finally, we observe that restarted builds have a major
impact on development workflow. Indeed, in 54.42% of the restarted builds, the
developers analyze and restart a build within an hour of the initial failure.
This suggests that developers wait for CI results, interrupting their workflow
to address the issue. Restarted builds also slow down the merging of pull
requests by a factor of three, bringing median merging time from 16h to 48h
Contextual Predictive Mutation Testing
Mutation testing is a powerful technique for assessing and improving test
suite quality that artificially introduces bugs and checks whether the test
suites catch them. However, it is also computationally expensive and thus does
not scale to large systems and projects. One promising recent approach to
tackling this scalability problem uses machine learning to predict whether the
tests will detect the synthetic bugs, without actually running those tests.
However, existing predictive mutation testing approaches still misclassify 33%
of detection outcomes on a randomly sampled set of mutant-test suite pairs. We
introduce MutationBERT, an approach for predictive mutation testing that
simultaneously encodes the source method mutation and test method, capturing
key context in the input representation. Thanks to its higher precision,
MutationBERT saves 33% of the time spent by a prior approach on
checking/verifying live mutants. MutationBERT, also outperforms the
state-of-the-art in both same project and cross project settings, with
meaningful improvements in precision, recall, and F1 score. We validate our
input representation, and aggregation approaches for lifting predictions from
the test matrix level to the test suite level, finding similar improvements in
performance. MutationBERT not only enhances the state-of-the-art in predictive
mutation testing, but also presents practical benefits for real-world
applications, both in saving developer time and finding hard to detect mutants
Mind the Gap: The Difference Between Coverage and Mutation Score Can Guide Testing Efforts
An "adequate" test suite should effectively find all inconsistencies between
a system's requirements/specifications and its implementation. Practitioners
frequently use code coverage to approximate adequacy, while academics argue
that mutation score may better approximate true (oracular) adequacy coverage.
High code coverage is increasingly attainable even on large systems via
automatic test generation, including fuzzing. In light of all of these options
for measuring and improving testing effort, how should a QA engineer spend
their time? We propose a new framework for reasoning about the extent, limits,
and nature of a given testing effort based on an idea we call the oracle gap,
or the difference between source code coverage and mutation score for a given
software element. We conduct (1) a large-scale observational study of the
oracle gap across popular Maven projects, (2) a study that varies testing and
oracle quality across several of those projects and (3) a small-scale
observational study of highly critical, well-tested code across comparable
blockchain projects. We show that the oracle gap surfaces important information
about the extent and quality of a test effort beyond either adequacy metric
alone. In particular, it provides a way for practitioners to identify source
files where it is likely a weak oracle tests important code
TarTar: A Timed Automata Repair Tool
We present TarTar, an automatic repair analysis tool that, given a timed
diagnostic trace (TDT) obtained during the model checking of a timed automaton
model, suggests possible syntactic repairs of the analyzed model. The suggested
repairs include modified values for clock bounds in location invariants and
transition guards, adding or removing clock resets, etc. The proposed repairs
are guaranteed to eliminate executability of the given TDT, while preserving
the overall functional behavior of the system. We give insights into the design
and architecture of TarTar, and show that it can successfully repair 69% of the
seeded errors in system models taken from a diverse suite of case studies.Comment: 15 pages, 7 figure
- …